1. Field of the Invention
The present disclosure relates generally to a wireless communication system, and more particularly, to a method and an apparatus for reducing the delay that occurs in a wireless communication system supporting a broadcast service.
2. Description of the Related Art
With the development of multimedia broadcast/communication technology capable of providing mass multimedia services, a broadcast service can be provided to a plurality of User Equipments (UEs). An example of a typical broadcast service is a Multimedia Broadcast/Multicast Service (MBMS).
MBMS is a broadcast service that supports transmission of various types of multimedia such as, for example, real-time videos, audios, still images and texts. MBMS is also a broadcast service that can provide audio data and video data at the same time. A large amount of transmission resources are required for MBMS. MBMS may be serviced over a broadcast channel because of the possibility that a plurality of UEs may exist for the same service.
In addition, a Long Term Evolution (LTE) system proposed in 3rd Generation Partnership Project (3GPP), which is the communication standard group, may provide not only a unicast service that is based on a Point-to-Point (PtP) communication scheme, but also a multicast service that is based on a Point-to-Multipoint (PtM) data transfer scheme. In the LTE system, a multicast data transfer scheme is called ‘eMBMS’.
It is assumed herein that the wireless communication system is an LTE system, and the term ‘MBMS’, as used herein, may refer to the eMBMS.
MBMS may provide the same broadcast service to a plurality of UEs located in a specific area. Herein, an area in which the same broadcast service is provided will be defined as an MBMS Single Frequency Network (MBMSFN) area having one or multiple cells or evolved Node Bs (eNBs). In the MBMSFN area, since broadcast data is synchronized and then transmitted through one or multiple cells, the MBMSFN area may be construed as a network area including one or multiple eNBs that transmit synchronized broadcast data. Different MBMSFN areas may overlap with one cell. MBMSFN transmission (hereinafter, referred to as MBMS transmission) may require not only time synchronization between cells participating in the MBMSFN area, but also use of the same set of wireless resources by each of the cells.
The MBMS transmission uses a Multicast Channel (MCH), and the MCH includes: a Multicast Traffic Channel (MTCH) which is a logical channel for transmitting broadcast data of each MBMS; and a Multicast Control Channel (MCCH) which is a logical channel for transmitting control information necessary for reception of broadcast data of each MBMS.
Transmission of the MCH may accompany MCH Subframe Allocation (MSA), and the MSA may be periodically performed at the beginning of each MCH Scheduling Period (MSP). MSP, specified in the 3GPP standard, may have a range of, for example, 80 milliseconds (ms) to 10.24 seconds (s). In the MCH transmission, an MCCH may be repeatedly transmitted depending on an MCCH repetition period, and may be changed depending on an MCCH modification period.
In the 3GPP standard, the MCCH modification period is specified as, for example, 512 ms or 1024 ms, and due to the MCCH modification period, data transmission of an MBMS session may be randomly delayed for 5.12 seconds or more. This transmission delay may occur only in an MBMS session for MBMS transmission requiring synchronization between eNBs, unlike the unicast traffic, causing a decrease in the quality of service in MBMS. For example, if the user is in a stadium, there may be a large time difference between the video that is displayed on a UE through MBMS, and the actual scene that the user watches in the stadium. In addition, when the user enjoys a Push To Talk (PTT) service or a group call, which is a voice service, through MBMS, a significant delay may occur until the voice of the user is heard by the user.
Since the MCCH modification period is limited to a minimum of 5.12 seconds as stated above, a long time delay of 5.12 seconds or more may occur until the data transmitted from the network is received at the UE. Thus, a time gap of 5.12 seconds or more may occur between the actual scene and the live voice and video received at the UE during the live broadcast through MBMS.
The long time delay is described in detail with reference to FIGS. 1A and 1B. FIG. 1A is a diagram illustrating a case in which a packet is transmitted without a significant delay since the data transmitted from a Broadcast Multicast Service Center (BMSC), which is a broadcast server, arrives at an eNB just before an MTCH is opened. On the other hand, FIG. 1B is a diagram illustrating a case in which a significant packet delay occurs if an MTCH channel is opened about 5 seconds after the data transmitted from the BMSC is received at the eNB. The packet delay as in FIG. 1B may occur because the BMSC does not correctly know the time the eNB prepares wireless resources and opens an MTCH.
In addition, even though the BMSC can estimate the time the eNB opens an MTCH, the significant packet delay, as shown in FIG. 1B, may occur because a packet may hardly arrive at an eNB in a predetermined time due to a delay occurring in a backhaul. A packet transmission time should be matched between eNBs, but all of the eNBs may be different in terms of the time each eNB receives a packet from the BMSC, due to the backhaul delay.
Because the eNBs are all different in terms of the time that each eNB receives a packet from the BMSC, in order to match the packet transmission time among the eNBs, a Multi-cell multicast Coordination Entity (MCE) may determine an MCCH update time and provide information about the determined MCCH update time to all eNBs in the MBMSFN area. Each eNB may open an MTCH (session) depending on the MCCH update time determined by the MCE, and start transmitting the packet sent by the BMSC.
When transmitting MBMS data, each eNB may determine the time it transmits the data, based on the timestamp value in the MBMS data. For example, if a timestamp value is ‘10’ and an offset value of a System Frame Number (SFN) is 512, then the eNB may transmit the packet when an SFN value is 522 (=512+10). The MCCH update time determined by the MCE may be determined as the closest MCCH modification boundary depending on the MCCH modification period (e.g., 5.12 seconds, 10.24 seconds, etc.), considering an MCCH notification time period. If the MCCH update time is determined in this way, MBMS data of the relevant session may be transmitted from that time on.